今天筆者實際跑一輪 Spec-Kit 的 SDD 流程，從 Spec、Plan、Task、Implement 到實作與驗證，順便看看 Token 到底是怎麼被吃掉的 😅

這套流程真的很完整，完整到有一點「你只是想算 BMI，結果它幫你規劃人生」的感覺啊。

🧭先修正一個流程：Checklist 要放在 Plan 後面
筆者先自首一下，前一天寫流程時，把 Checklist 和 Plan 的順序搞反了。 原本以為只是文件順序，應該還好，結果實際跑過才發現，這個順序其實有邏輯： 必須先完成 Plan，讓系統知道要採用什麼技術與架構，接著才有辦法根據計畫做 Checklist。

SDD 是一條從需求到驗證的連續工作流，順序不能隨便亂插隊。

這次筆者把之前的繁體中文影片轉成英文版的範例網站，讓 AI 依照流程去分析、規劃與實作。 結果它不只產生原本預期的幾個檔案，還衍生出一大串研究、資料模型、測試與工作文件。

除了主要文件，還會產生不少輔助檔案。

🔥 Token 魔王登場：為什麼 SDD 這麼會吃？
筆者第一次完整跑十個步驟時，真的有被嚇到。原本一般流程可能只會建立幾個主要工作， 結果用 SDD 跑下去，居然一路增加到 53 個 jobs。

當時使用的是 Luna，Context Window 是一百萬 Token。看起來很大對不對？ 但流程還沒完成，就已經吃掉大約 10%～15% 了。這代表什麼？ 如果是在上半年、還沒有這類相對省 Token 的模型之前，可能一個月二十美元的訂閱， 跑一個 SDD 專案就先燒掉一半，甚至直接燒完啊

文件越完整，Token 消耗也會跟著增加。

💸 Token 成本的實務觀察
SDD 會反覆閱讀與確認 Spec、Plan、Tasks 及相關檔案。
每個階段可能額外建立研究文件、Data Model、測試規劃。
流程越完整，AI 的推理與檔案操作越多，Token 自然不會客氣。
它不是單純的缺點，因為它確實非常仔細，只是荷包要有心理準備。
所以這不是「SDD 很爛、很浪費」這麼簡單。它是真的很仔細，甚至仔細到筆者需要一個個檔案確認。 但如果只是做一個小工具，這種規模就像去巷口買一杯珍奶，結果開了 ERP、做了採購流程、還安排稽核，實在有點 over。

這次筆者也順便提到了 Matt 與 Uncle Bob 的對談。如果對 Vibe Coding 或 AI 輔助開發有興趣， 這段內容真的很值得看。

🏗️ Uncle Bob 的提醒：「Specify、Specify、Specify」——聽起來是不是有一點熟悉？
Uncle Bob 提到，SDD 不斷要求人類把需求 Specify 清楚，這種精神其實很像 1970 年代的 Waterfall。 台灣寫軟體接案的朋友對 Waterfall 應該不陌生，畢竟台灣很多專案因為要請款，規格書厚到可以拿來墊便當啊。

另外Uncle Bob 用蓋房子比喻 AI 軟體開發也很傳神：設計圖重要，但成本結構已經改變。如果蓋房子的成本很低，還需要花大錢畫一份昂貴的設計圖嗎？
這個比喻很有意思。傳統軟體開發中，推倒重來的成本很高，所以前期規格與設計圖非常重要。 但 AI Coding 讓「重新產生一版」變得便宜很多，某些小型專案不一定需要非常厚重的規格流程。

當然，這不代表需求可以亂寫。筆者的理解是：AI 降低了重做成本，但沒有消滅複雜度。 專案越大、風險越高，前期的規格、驗證與追蹤仍然很重要。

📝 實際跑 Spec-Kit：一個 BMI Calculator 也能寫得像商業系統
這次筆者拿一個 BMI Calculator 當範例，需求看起來很簡單吧？ 輸入身高、體重，算出 BMI，再顯示分類。結果 SDD 還是幫我拆出了多個 User Story， 並且列出九個 Function Requirement，連可測量的結果與驗收條件都寫得清清楚楚。

從 User Story 到 Function Requirement，需求描述會被拆得很細。
這就是 SDD 的強項：它不滿足於「做一個 BMI 計算器」這種模糊描述， 而是繼續追問輸入格式、錯誤處理、結果分類、成功條件，以及哪些結果要能被測試。

更多實作Demo，請參考完整版影片囉

🧠 本日結論：找到自己的開發流派

SDD 的優點
需求、設計、任務與程式碼之間有清楚的關聯。
容易留下完整的開發軌跡，方便日後追蹤。
測試與驗收條件較完整，不容易只做到「看起來能動」。
適合中大型、商業流程、多人協作與高風險需求。

SDD 的缺點與踩坑
文件與 jobs 數量會快速膨脹。
Token 消耗明顯，訂閱額度有限時要特別小心。
小需求使用完整流程，可能比直接寫程式還慢。
AI 可能主動補上未要求的功能，造成 over-design。
人類仍然要逐項 Review，不是按下按鈕就能去泡茶。

筆者認為，SDD 沒有絕對好或壞，重點是要找到適合自己的開發方式。 別人的流程可以拿來學習，但不能整套照抄，因為每個人的專案規模、風險、團隊文化與預算都不一樣。

如果是自己做的小工具、練手作品，筆者會選擇比較輕量的流程： 先寫清楚目標，讓 AI 產生初版，再針對關鍵功能補測試與 Review。 沒必要每次都開滿十個魔王關卡，做個計算機也要開企業架構審查會議，頭都洗了才發現只是洗手。

但如果是中大型商業需求，SDD 就值得考慮。畢竟SDD是一個完整開發流程，而且前後勾稽，這個單靠Vibe Coding幾句 Prompt 是做不太到的。